ひとりNavigation API Advent Calendar 25日目
https://gyazo.com/52e7ff48e2e50f7b535c75a189df94e5
これはひとりNavigation API Advent Calendarの25日目です。
最終日はひとりNavigation API Advent Calendarの総括をしていきたいと思っています。
Navigation APIについての理解が深まったか
もともとはyamanoku.iconの理解を深めるためにはじめたアドベントカレンダー
何も見ずに解説できるほど完全にAPIの内容を理解できているわけではない
ただ、どういう挙動をしたものでどういうことができるかのおおまかな内容は把握できたと思っている
特に intercept() の強力な部分が知れた
標準で中断ができちゃうすごさよ
でも代わりに悪いことにも応用できそうかもなと思った
ひとりNavigation API Advent Calendar 20日目で書いた
これはNavigation APIが悪いのではなく、悪いことがやりやすくなるよね、みたいなこと
同一オリジンの中での挙動ではあるが、サイト内部で広告入れ込みとか使われると…
BFCacheのそれよりも明示的になりそう
commitがどういう挙動なのかはざっくりとした理解になっている
ひとりNavigation API Advent Calendar 14日目でNavigation APIでクライアントサイドルーティングが作れたことでHistory APIとの差分が理解できた
<a>の遷移中断処理が不要になるのはでかい
これによりSvelteKitやAstroのクライアントサイドルーティングのルーターのコンポーネントが不要だったところの理解にも繋がった
今回の調査を経てSvelteKitやAstroはJavaScriptだけではなくHTML含めたWeb標準に倣おうとするフレームワークなんだなという印象をもちました
Kenjiさんよりコメントもらっていたのを勝手に紹介
@jp_knj: やまのくさんの話とは全然、関係ないですけど。AstroのView Transitionsは、ブラウザのView Transition APIを扱いやすくするためのラッパーに近いことが明確になるなーと。ここで学ぶべきなのはAstroの作法そのものより、ページ遷移の体験がブラウザ標準としてどう進化しているかという点です。
@jp_knj: Astroを学ぶことは、Webを学ぶことにつながる。Astroを“目的”にせず、Web標準への導線にする。これがコンテンツとしての長期価値を作り、ウェブの学習コストも下げる気がしてきました。
仕様を追っていたおかげでFUNSTACK Routerの内部もどうなっているかコードリーディングしやすかった
というかこのひとりNavigation API Advent Calendar中にいきなり出現してびっくりした
yamanoku.iconは引き続きFUNSTACK Routerの開発を応援していきます
実際の細かな挙動までは追いきれなかったのでそれは引き続き見ていくと思っています
副次的にTypeScriptへのDOM API型定義追加タイミング、WPTやIntent to Shipなどの標準化への動きを知ることもできて良かったです
これからのルーターライブラリのエコシステムについて
ここで言及するのは主にクライアント側の方です
おそらく来年からはNavigation APIがNewly Baselineになると思う
最後のブラウザとしてFirefoxが来年1月以降に安定版で使えるようになるので
それによってルーターライブラリはNavigation APIへの移行が進んでいくはず
現状のHistory APIでは不安定なため、望んでいたことではあると思う
が、移行においてはHistory APIと置き換わる大きな変更となるため一定時間はかかると思う
まだ明確にNavigation APIへの移行を宣言しているものはないはず
Discussionでの提案はある
https://github.com/remix-run/react-router/discussions/11046
https://github.com/TanStack/router/discussions/821
Vue Routerは明確な宣言は見られないが移行途中っぽい
feat: add navigation-api router by userquin · Pull Request #2551 · vuejs/router · GitHub
今後の移行においてはライブラリを使う側、つまりユーザー側はどうなるのか気になる
History APIモード自体は残すとして非推奨にしていくのか
履歴についてはHistory API自体には依存するものではないが…
あるいはNavigation APIの方に完全に移行していくのか
この部分はライブラリ作者としての解像度が低いのでどうしたいかがわかっていません
今回、それら全てを見ることはできなかったので、ここも引き続き注視していきたいなと思っています
SPAという体験は今後どうなっていくのか
Navigation APIはSPAのユーザー体験や開発体験そのものを改善してくれるものだけど、それによってSPAが今後どうなっていくかはまだ見えていない
つまり我々はSPAに対してどういうものを望んでいるのか、という点
Webアプリケーションの体験としてはネイティブアプリと近いスムーズさを望んでいると思う
つまり「よりWebらしさを消していく」ということ
PWAというものがそれだったと思うけど、今は概念が消滅しているし…
シームレスな移動というのはView Transitions APIと地続きでやっていけそうに思える
今のNavigation API単体でどう良くなるかは正直見えていないのでなんらかの機能が加わることで進化していけるといいのかな
SPAのルーティング処理が安定していけることはいいことだと思っています
何が欲しいのかはユーザー側で考えていきたいところです
yamanoku.iconはRoute Announcerの仕組みがWeb標準側で策定されるといいなと思っています
WAI-ARIAのroleでそういうものがあったらいいのかな？
ARIA Notify APIってのがあったな…
この要望がより明らかになっていけばルーターライブラリ側も変わってくるのかもしれない
ネイティブアプリとしてではなくWebとしての良さを残したうえで新たな体験を生み出せるのはこうした領域ではないだろうか？と思っています
ひとりNavigation API Advent Calendar後にやっていきたいこと
Navigation APIでクライアントサイドルーティングを作って内容を理解するコンテンツを作りたい
実はリポジトリはすでにあります
yamanoku/chibirouter · GitHub
chibivueリスペクトです
FUNSTACK Routerのようなものを作るのではなく、理解するためのコンテンツをつくるのが主目的
最小のクライアントサイドルーティング機構を作り、内部を理解するためのもの
MDN Web DocsのNavigation APIの日本語翻訳
まだ未着手っぽいので翻訳に参加していきたい
来年中には全部日本語訳されているようにしたいな
ページ数も多いので協力者も募集したいです！一緒にやりましょう！
JSConfJP（あるいは何らかのフロントエンドカンファレンス）での登壇・発表
Navigation APIに関するコンテンツで登壇したい
ただ仕様を説明するだけでは新規性もないので自分と関連しそうな話も入れたい
各種クライアントサイドルーティング動向についてもウォッチしていってその内容を解説したい
蛇足：Navigation APIそのものとは関係ないひとりアドベントカレンダーの部分
Cosenseでやっていけたのがよかった
ブログみたいな形で公開するよりも手間が少ない
ページがまだ作られなくてもページのURL自体にはアクセスできるので404にならない
そのままURLが日本語になってしまうのはまぁしょうがない
ちょうどSPAのルーティングを題材にしたのでNavigation APIで扱うにはちょうどよい場であったのは後から気づいた
来年、またひとりアドベントカレンダーをやるかは分かりませんが学習帳としてCosenseでやっていくのはアリだなと思っています
Nani翻訳が本当に体験よかったです
仕様の翻訳とかに手伝ってもらいました
速度が速いだけでなく、簡単に言うと～みたいなオプションがあるのも良き
使いすぎて途中で制約食らっちゃったのですが、Chrome拡張機能が出たら課金するのでcatnoseさんよろしくお願いします！！！！！
以上、ひとりNavigation API Advent Calendar、お疲れさまでした！